home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000056_news@newsmaster….columbia.edu _Sun Oct 5 21:12:51 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA17581
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sun, 5 Oct 1997 21:12:50 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id VAA05807
  7.     for kermit.misc@watsun; Sun, 5 Oct 1997 21:12:50 -0400 (EDT)
  8. Path: news.columbia.edu!panix!news.eecs.umich.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  9. From: jrd@cc.usu.edu (Joe Doupnik)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Kermit via PPP under DOS?
  12. Message-ID: <4TpKBo0duVW2@cc.usu.edu>
  13. Date: 5 Oct 97 08:40:36 MDT
  14. References: <k1c7kBQEU5Wv@cc.usu.edu> <omraa16rl3.fsf@tees.cs.ualberta.ca>
  15. Organization: Utah State University
  16. Lines: 108
  17. Xref: news.columbia.edu comp.protocols.kermit.misc:7827
  18.  
  19. In article <omraa16rl3.fsf@tees.cs.ualberta.ca>, Vladimir Alexiev <vladimir@cs.ualberta.ca> writes:
  20. > In article <XrKuqa+e0PBq@cc.usu.edu> jrd@cc.usu.edu (Joe Doupnik) writes:
  21. > 
  22. >> > the fact remains that these apps can use emulated class 1 drivers, while
  23. >> > Kermit can't. Sometimes worse is better.
  24. >>     This looks more and more like an argument waiting to happen, due to
  25. >> lack of specific information.
  26. > 
  27. > Talk by Michael Ringe <michael@thphys.physik.rwth-aachen.de> which is "built
  28. > upon the WATTCP library" works with EPPPD which is a class 1 PPP driver.
  29. > Kermit's TCP is also built over the WATTCP library (if information on WATTCP's
  30. > site is correct), but I guess that Joe has introduced changes that make it
  31. > incompatible with drivers emulating class 1 (Internet).
  32.  
  33.     Kermit's TCP/IP stack is based upon the WATTCP of over six years ago
  34. and followed its own development/evolutionary path to be a different set of 
  35. code. Similarly the WATTCP of that era has itself developed and evolved to
  36. be the WATTCP of today. Neither is even nearly the same as their 1991 versions.
  37. Today the two sets of code are very different indeed. I've said this before.
  38.  
  39.     Class 1 Packet Drivers have no identification with "Internet"; we
  40. presume that's your name for IP packets. They purport to deal with frames on
  41. Ethernet. MS-DOS Kermit runs just fine over Class 1 Ethernet Packet Drivers, 
  42. if those drivers do their job correctly.
  43.     Again here are fundamentals and I hope you pause to understand this.
  44. A Packet Driver advertisizing itself as Ethernet (Class 1) on the top tells
  45. the application protocol stack that Ethernet is the lan topology and hence
  46. Ethernet rules apply. Amongst them are supporting MAC addresses, identifying
  47. stations in the same broadcast domain (and hence IP subnet) by physical layer
  48. broadcasts and direct MAC addressing (no router), and having an IP gateway to
  49. contact stations not in the same broadcast domain. An ARP for one's own IP 
  50. address, for example, must fail to yield a response, and an ARP for another
  51. station on the same IP subnet must yield a proper response (or none if the
  52. station is not reachable by IP at that time). This is in addition to framing
  53. details. Ethernet runs this way.
  54.     Let me emphasize this point again. Frame construction is only part
  55. of the situation. Supporting a broadcast medium via physical addresses is
  56. another part, and it is the part that is easily broken in emulation. Both
  57. parts are intrinsic components of Ethernet. See my comment on "fundamentals"
  58. below.
  59.     If a PPP or carrier-pigeon or whatever driver advertisizes itself
  60. as Ethernet to the protocol stack then it must emulate Ethernet 
  61. characteristics to the protocol stack. 
  62.  
  63. >> I thought I explained the difficulties with a driver purporting to be
  64. >> Ethernet but isn't; they are fundamental.
  65. > 
  66. > How do you explain then that that talk program works? I also tried
  67. > successfully the telnet from NUPop over the same EPPPD driver, however NUPop
  68. > is not WATTCP-based. Would you like me to test WATTCP FTP or a WATTCP-based
  69. > telnet client (where is one)?
  70. >
  71.     I have not the slightest idea of what code is in those programs. 
  72. Have you looked at them to see what they do internally? How about the
  73. internals of those PPP drivers? What are those drivers really doing?
  74.  
  75. >> > Well, these half measures prove to be adequate for other WATTCP apps.
  76. >>     which are tailored for a point to point link, no doubt.
  77. > I don't think so. I don't have an ethernet connection I can try them with, but
  78. > their docs claim they work over ethernet too. It wouldn't make much sense if
  79. > they didn't.
  80. >
  81. >> > - there are apps that only support ethernet interfaces. Kermit couldn't
  82. >> >   coexist with such apps because it demands a SLIP interface.
  83. >>     Argumentative again. No, Kermit does not "demand" SLIP,
  84. > If Kermit is to be used with a serial link (SLIP or PPP), the packet driver
  85. > has to support class 6 (SLIP) interface. Obviously all SLIP drivers do, but
  86. > only two out of the three freely available PPP drivers do (dosppp and
  87. > MeritPPP, aka etherppp or ethernew), while ppppkt does not. More important
  88. > however is that if one would like to use another TCP app together with Kermit,
  89. > that app should also support class 6, because a driver can only run in one of
  90. > the class modes that it supports at a time.
  91.  
  92.     We do not support any attempt to run two TCP/IP stacks over the same
  93. lan driver, period. Folks may be succussful at times with pktmux, but that
  94. is not an item or area we are prepared to support in any way. Why? Because
  95. it is not possible to cleanly separate two or more stack's this way, despite
  96. the good work in pktmux. 
  97.  
  98. >> but if the alternatives fail to meet specs then that is hardly Kermit's
  99. >> fault.
  100. > What spec does a working combination "class 1 PPP driver" - "class 1 app" fail
  101. > to meet? You seem to assert that class 1 emulating serial drivers are
  102. > impossible, yet there are at least 3 such: dosppp, MeritPPP, pppshare/pppdemo.
  103.  
  104.     No such assertion has been made by me. You are the guy going to
  105. extremes. 
  106.  
  107. >> > Is BOOTP impossible with a SLIP interface? How about DHCP?
  108. >> Both use UDP over IP. How IP gets put onto the wire is another matter.
  109. > Yes, I can't think of a good reason why BOOTP shouldn't work either, but the
  110. > class 6 driver in dosppp (PPPD) doesn't support it for some reason.
  111. > 
  112. >> Please do keep in mind that both BOOTP and DHCP are sensitive to physical
  113. >> address
  114. > Why? Isn't it only critical for RARP (which resolves an Ether address to an
  115. > IP address)? I guess it depends a lot on the remote side as well, because most
  116. > often the remote gives us our IP.
  117.  
  118.     It might be beneficial to review the specs of BOOTP and DHCP.
  119.  
  120. > 
  121. >> > How about Windows PPP drivers, do they support an Ethernet interface?
  122. > 
  123. > (Forget about this, my mind was probably clouded when I wrote it; Windows
  124. > drivers are not packet drivers.)
  125.  
  126.     Joe D.